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Abstract. Web service compositions are gaining attention to develop 
complex web systems by combination of existing services. Thus, there 
OO , are many works that leverage the advantages of this approach. However, 

there are only few works that use web service compositions to manage 
distributed resources. In this paper, we then present a formal model that 
combines orchestrations written in BPEL with distributed resources, by 
using WSRF. 
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1 Introduction 



f— ^ , Software systems are gaining complexity and concurrency with the appearance 

\^ ' of new computational paradigms such as Service- Oriented Computing (SOC), 

C^^ , Grid Computing and Cloud Computing. In this kind of systems, the services 

provider needs to ensure some levels of quality and privacy to the final user in a 
fT^ , way that had never been raised. Therefore, it is necessary to develop new models 

C^ ■ yielding the advantages of recent approaches as web services compositions, but 

applied to these recent scenarios. To this end, we have worked up an operational 
semantics to manage web services with associated resources by using the existing 
machinery in distributed systems, web services orchestrations. 

The definition of a web service-oriented system involves two complementary 
""^Jj , views: Choreography and Orchestration. On the one hand, the choreography 

^j concerns the observable interactions among services and can be defined by using 

specific languages, e.g., Web Services Choreography Description Language (WS- 
CDL) [IS]. On the other hand, the orchestration concerns the internal behavior 
of a web service in terms of invocations to other services. Web Services Business 
Process Execution Language (WS-BPEL) [T] is usually used to describe these 
orchestrations, so this is considered the de facto standard language for describing 
web services workflow in terms of web service compositions. 

In this scenario, developers require more standardization to facilitate addi- 
tional interoperability among these services. Thus, in January of 2004, several 
members of the organization Globus Alliance and the computer multinational 
IBM with the help of experts from companies such as HP, SAP, Akamai, etc. 
defined the basis architecture and the initial specification documents of a new 



standard for that purpose, Web Services Resource Framework (WSRF) [S]. Al- 
though the web service definition does not consider the notion of state, interfaces 
frequently provide the user with the ability to access and manipulate states, i.e., 
data values that persist across, and evolve as a result of web service interac- 
tions. It is then desirable to define web service conventions to enable the dis- 
covery of, introspection on, and interaction with stateful resources in standard 
and interoperable ways 4^ . These observations motivated the appearance of the 
WS-Resource approach to modeling states in web services. 

In WSRF, we can see a WS-Resource as a collection of properties P identified 
by an address EPR and with a timeout associated. This timeout represents the 
lifetime of the WS-Resource. Without loss of generality, we have reduced the 
resource properties set to only one allowing us to use the resource identifier 
EPR as the representative of this property. On the BPEL hand, we have only 
taken into consideration the root scope avoiding any class of nesting among 
scopes and we have only modeled the event and fault handling, leaving the other 
handling types as future work. 

2 Related Work 

The use of WS-BPEL has been extensively studied by using different types of 
formalism such as Petri nets. Finite State Machines and process algebras. Re- 
garding the use of WS-BPEL together with WS-RF there are few works, and 
they only show a description of this union, without a formalization of the model. 
In [2] Slomiski uses BPEL4WS in Grid environments and discusses the benefits 
and challenges of extensibility in the particular case of OGSI workflows combined 
with WSRF-based Grids. Other two works centered around Grid environments 
are [10] and [7]. The first justifies the use of BPEL extensibility to allow the 
combination of different GRIDs, whereas Ezenwoye et al. [7] share their experi- 
ence on BPEL to integrate, create and manage WS-Resources that implement 
the factory/instance pattern. 

On the Petri nets hand, Ouyang et al. [12] define the necessary elements for 
translating BPEL processes into Petri nets. Thus, they cover all the important 
aspects in the standard such as exception handling, dead path elimination and 
so on. The model they consider differs from ours in that we formalize the whole 
system as a composition of orchestrators with resources associated, whereas they 
describe the system as a general scope with nested sub-scopes leaving aside the 
possibility of administering resources. Furthermore, we have also formalized the 
event handling and notification mechanisms. Another extensive semantics for 
BPEL 2.0 is presented in [6] by Dumas et al, which introduces two new interest- 
ing improvements. They define several patterns to simplify some huge nets and 
introduce the semantics for the WS-BPEL 2.0 new patterns. On the 7r-calculus 
hand, Dragoni and Mazzara [5] propose a theoretical scheme focused on depend- 
able composition for the WS-BPEL recovery framework. In this approach, the 
recovery framework is simplified and analyzed via a conservative extension of 
TT-calculus. The aim of this approach clearly differs from ours, but it helps us 



to have a bigger understanding of the WS-BPEL recovery framework. Other 
work focused on the BPEL recovery framework is [T3]. Although this is more 
interested in the compensation handler, they describe the corresponding rules 
that manage a web service composition. Our work is therefore quite complete 
as we define rules for nearly all possible activities. In addition, we also consider 
time constraints. Finally, we would like to highlight the works of Farahbod et 
al. [S] and Busi et al. |3j. In the first one, the authors extract an abstract op- 
erational semantics for BPEL based on abstract state machines (ASM) defining 
the framework BPEL^im to manage the agents who perform the workflow activ- 
ities. In this approach time constraints are considered, but they do not formalize 
the timed model. On the other hand, the goal of the latter one is fairly simi- 
lar to ours. They also define a 7r-calculus operational semantics for BPEL and 
describe a conformance notion. They present all the machinery to model web 
service compositions (choreographies and orchestrations). The main differences 
with our work are that we are more restrictive with respect to time constraints 
and we deal with distributed resources. 



3 BPEL/WSRF 

WS-Resource Framework [2] is a resource specification language developed by 
OASIS and some of the most pioneering computer companies, whose purpose is 
to define a generic framework for modeling web services with stateful resources, 
as well as the relationships among these services in a Grid/ Cloud environment. 
This approach consists of a set of specifications that define the representation 
of the WS-Resource in the terms that specify the messages exchanged and the 
related XML documents. These specifications allow the programmer to declare 
and implement the association between a service and one or more resources. 
It also includes mechanisms to describe the means to check the status and the 
service description of a resource, which together form the definition of a WS- 
Resource. In Table [T] we show the main WSRF elements. 

On the other hand, web services are becoming more and more important as 
a platform for Business-to-Business integration. Web service compositions have 
appeared as a natural and elegant way to provide new value-added services as 
a combination of several established web services. Services provided by different 
suppliers can act together to provide another service; in fact, they can be written 
in different languages and can be executed on different platforms. As we noticed 
in the introduction, we can use web service compositions as a way to construct 
web service systems where each service is an autonomous entity which can offer 
a series of operations to the other services conforming a whole system. In this 
way, it is fairly necessary to establish a consistent manner to coordinate the 
system participants such that each of them may have a different approach, so it 
is common to use specific languages such as WS-BPEL to manage the system 
workfiow. WS-BPEL, for short BPEL, is an OASIS orchestration language for 
specifying actions within web service business processes. These actions are rep- 
resented by the execution of two types of activities ( basic and structured) that 



Name 


Describes 


WS-ResourceProperties 


WSRF uses a precise specification to define the properties of the 
WS-Resources. 


WS-Basefaults 


To standardize the format for reporting error messages. 


WS-ServiceGroup 


This specification allows the programmer to create groups that 
share a common set of properties. 


"WS-ResourceLifetime 


The mission of this specification is to standardize the process of 
destroying a resource and identify mechanisms to monitor its 
lifetime. 


WS-Notification 


This specification allows to a Notification Producer to send 
notifications to a NotificationConsumer in two ways: without 
following any formalism or with a predefined formalism. 



Table 1. WSRF main elements 



perform the process logic. Basic activities are those which describe elemental 
steps of the process behavior and structured activities encode control-flow logic, 
and can therefore contain other basic and/or structured activities recursively [1] . 



4 Operational Semantics 



We use the following notation: ORCH is the set of orchestrators in the system, 
Var is the set of integer variable names, PL is the set of necessary partner links, 
OPS is the set of operations that can be performed, EPRS is the set of resource 
identifiers, and A is the set of basic or structured activities that can form the 
body of a process. The specific algebraic language, then, that we use for the 
activities is defined by the following BNF-notation: 

A ::— throw \ receive{pl,op,v) \ invoke{pl^op,vi) 
reply{pl,v) \ reply{pl,V2) \ assign{expr,vi) \ wait (timeout) \ 
empty \ exit \ A; A \ A\\A \ while{cond, A) 
pick{{{pk, opi,Vi, Ai)]"^^^, A.timeout) \ 
createResource{EPR, val, timeout, Ae^) \ getProp{EPR,v)\ 
setProp(EPR,val) \ setTimeout{E PR, timeout) 
subscribeiO , EPR, cond' , A,,. ) 

where O e ORCH, EPR e EPRS, pi, pk e PL, op, op, e OPS, timeout G IN, expr 
is an arithmetic expression constructed by using the variables in Var and inte- 
gers; V, vi,V2, Vi range over Var, and val e Z. A condition cond is a predicate 
constructed by using conjunctions, disjunctions, and negations over the set of 
variables Var and integers, whereas cond' is a predicate constructed by using 
the corresponding EPR (as the resource value) and integers. 

BPEL basic activities used in our model are: invoke to request services offered 
by service providers, receive and reply to provide services to partners, throw to 



signal an internal fault explicitly, wait to specify a delay, empty to do nothing, 
exit to end the business process and assign, which is used to copy data from a 
variable to another. And the structured activities used are: sequence, which con- 
tains two activities that are performed sequentially, while to provide a repeated 
execution of one activity, pick that waits for the occurrence of exactly one event 
from a set of events (including an alarm event), and then executes the activity 
associated with that event, and, finally, flow to express concurrency. Another 
family of control flow constructs in BPEL includes event, fault and compen- 
sation handlers. An event handler is enabled when its associated event occurs, 
being executed concurrently with the main orchestrator activity. Unlike event 
handlers, fault handlers do not execute concurrently with the orchestrator main 
activity [T^. The correspondence among the syntax of WS-BPEL, WSRF and 
our model is shown in Table [51 

An orchestration is now defined as a tuple O — {PL, Var, A, Af, Ae), where 
A and Af are activities defined by the previous syntax and Ae is a set of ac- 
tivities. Specifically, A represents the normal workfiow, Af is the fault handling 
activity and Ae = {^ei}™o ^^^ *^^ event handling activities. The operational 
semantics is, then, defined at three levels, the internal one corresponds to the 
evolution of one activity without notifications. In the second one, we define the 
orchestration semantics with notifications, whereas the third level corresponds 
to the composition of different orchestrators and resources to conform the chore- 
ography. We first introduce some definitions that are required in order to define 
the operational semantics. 

Definition 1 (States). We define a state as a pair s=(cr,p), where ct represents 
the variable values and p captures the resource state. Thus, a : Var — )■ Z, and 
p= {{EPRi, Vi, Subsi,ti, Aei)}l^j, where r is the number of resources in the 
system. Each resource has its own identifier, EPRi, and, at each state, has 
a particular value, Vi, and a lifetime, ti, initialized with the createResource 
function, which can be changed by using the function setTimeout. Moreover, 
Subsi = {{Oy, condl, Ae,. )}!Lj is the set of resource notification subscribers, 
their associated delivery conditions and the event handling activity Ae,. that 

must be thrown in the case that cond[ holds; Si is the number of orchestrations 
currently subscribed to this resource and Oi e ORCH are the subscriber's iden- 
tifiers. The operations are defined as follows: OPS = {opi\ opi : Z^'"' — s> Z^"''}. 
Given a state s = {cr,p), a variable v and an expression e, we denote by 
s' = {a[e/v], p) the state obtained from s by changing the value of w for the evalu- 
ation of e and .s+ = {a, p'), where p' = {{EPRi, Vi, Subsi, ti — 1 , Aei)\ti > l}^^^. 

a 

Next we define some notation that we use in the operational semantics. We em- 
ploy the notation EPRi £ p to denote that there is a tuple {EPRi, Vi, Subsi, fi, ^ej 
G p, i G [1 . . . r]. Given a predicate cond, we use the function cond{s) to mean 
the resulting value of this predicate at the state s. Besides, p[w/ EPR]i is used 
to denote that the new value in p of the resource EPR is w, p[t/EPR]2 denotes 
a change in the timeout attribute of the resource in p and 



WS-BPEL Syntax 


Mctamodel 


<proccss ...> 

<partnerLinks> ... < /pai:tnerLinks>? 

<Variables> ... < /Variables>? 

<faultHandlerB> ... </faultHandlers> ? 

<eventHandlcrs> ... </cvcntHandlci:s>? 
(activities)* 
</process> 


(PL,Var,A,Aj,Ae) 


throw/any fault 


throw 


<rcccivc partncrLink= "pi" opcration= "op" variablc= "v" crcatclnstancc= "no" > 
</ receive > 


reccivc(pl,op,v) 


<reply partncrLink= "pr' variablc= "v" > </rcply> 


reply{pl,v) 


< invoke partncrLink= "pi" op oration = "op" input Variablc= "v]^ " 
OutputVariablc="v2"> </invokc> 


invoke(pl,op,vi); [repi-y (pLop,V2 )] 


<empty> ... </cmpty> 


empty 


<cxit> . . . </cxit> 


exit 


<assign><copy><from>cxpr</from><to>vi</to></copy></aBsign> 


assign(cxpr,vi) 


<wait><for>timcout</for> </wait> 


wait{timeout) 


<scqucncc> 
activityi 
activity2 

</sequcnce> 


<flow> 
activityi 
activity2 

</flow> 


Ai ; A2 
Ai II A2 


<whilc>< condition >cond< /condition > activity! </ while > 


whilc(cond,A) 


<pick createInstance^"no" > 

<onMessage partncrLink= "pi" opcration= "op" variable= "v" > 
activity^ 

</onMessagc> 

<onAlarm><for>timcout</for>activityj^ < /on Alarm > 
</pick> 


pick({(p^, op^, -u^, A^)}'^^-^^, A, timeout) 


< invoke partncrLink= "Factory" operation^ "Create Resource" 

input Variable= "Messagein" output Variable^ "MessageOut" > 

</invoke>< assign >< copy > <from variable^ "MessageOut" >part= "param" 

query^"/test:CreateOut/wsa:endpointreference"</from> 

<to> partnerlink^ "Factory" </to></copy></assign> 


crcatcRcsourcc(EPR,val, timeout, Ag . ) 


<wsrp:GctResourceProperty> property 1 </wsrp:GetRcsourccPropcrty > 


gctProp(EPR,v) 


<wsrp:SetResourceProperties> 

<wsrp: Update > property ]^ </vi'srp:Update> 
< /wsrp:SetResourceProperties> 


setProp{EPR,val) 


<wsrl:SctTerminationTime> 

<wsrl:RequcstcdTcrminationTimc> 

timeout 
</wsrl:RequestedTerminationTimc> 

</wsrl:SetTerminationTime> 


sctTimcout(EPR,timcout) 


<wsnt:Subscribc> 

<wsnt: Consumer Refcrence>0</wsnt: Consumer Reference> 
<wsnt: Producer Reference>EPR</wsnt: ProducerReference> 
<wsnt:Precondition>cond'</Precondition> 

</wsnt:Subscribe> 


subscribe{0,EPR,cond\Ae. ) 


<wsnt:Notify> 
<wsnt:NotificationMessage> 
<wsnt:SubscriptionReference>0</wsnt:SubscriptionReference> 
<wsnt: Producer Reference>£;fK</wsnt:ProducerReference> 
<wsnt:Message> ... </wsnt:Message> 
</wsnt:NotificationMcssage> 
</wsnt:Notify> 


Spawn the associated event handler ac- 
tivity Ag . 



Table 2. Conversion table 



Add_.subs{p, EPRi, Oi , condl, Ae^. ) denotes that (Oi , condl, Ag^ ) is added to 
the subscribers of the resource EPRi G p or cond' ~ condl in the case that Oi 
was already in Suhsi. We need two additional functions. One of them, to extract 
the event handling activities that will be launched when the subscriber condition 

holdsat the current state s: A^(0, s) = {^e,. \{Oi-,cond[ , Af.,. ) & Subsi, Oi^ — O, 

ij J J ij 

condl = true}l^i and the other one is used to launch the activities when the 
resource hfetime expires: T{0, s) = {Ae^. \{EPRi, Vi, Subsi, 1 , Ae.^.) & p, O = 
Oi e Subsi}\^-i . Now, a partnerlink is a pair (O^, Oj) representing the two roles 
in communication: sender and receiver. 

Definition 2 (Activity Operational semantics). We specify the activity 
operational semantics by using two types of transition: 

a. (A,s)— > [A' ,s'), a £ Act (Action transitions). 

b. (A,s)-^i (A',s+) (Delay transitions). 

n 

where Act is the set of actions that can be performed, namely: Act — {r, throw, 
receive(pl,op,v), reply(pl,v), invoke(pl,op,vi), reply{p\,V2), assign(e,vi), empty, 
wait(timeout), exit, pick({(pli,opi,Vi,Ai)}f^]^, A, timeout), while(cond,A), 
createResource(EPR,val, timeout, AeJ, setProp(EPR,val), getProp(EPR,v), set- 
Timeout(EPR, timeout), and subscribe(0,EPR,cond',Ae. )}. Notice that we have 
included a r-action that represents an empty movement. 

Action transitions capture a state change by the execution of an action a G 
Act, which can be empty (r). Delay transitions capture how the system state 
changes when one time unit has elapsed. In Tables 14151 we show the rules of 
these transitions. 

When a resource has used up its lifetime or when a subscription condition 
holds, a specific notification is sent to the corresponding resource subscribers, 
which is captured by the rules in Table [51 In these rules, the parallel operator 
has been extended to spawn some event handling activities, which must run in 
parallel with the normal activity of an orchestrator. We therefore introduce the 
rules by using the following syntax for the activities in execution: {A, Ae), where 
A represents the normal system workflow, and Ae — {Af,.}^g are the handling 
activities in execution. Given any activity A, we write for short ^||.4e to denote 
(^IK^Ei IK- ■ • ||j4e,„))). We assume in this operator that those event handling 
activities that were already in Ae will not be spawned twice. 

Definitions (Operational semantics with notifications). We extend both 
types of transition to act on pairs (A, Ae)- The transitions have now the following 
form: 

a. (O : {A,Ae),s) A (O : (A',^'J,s'), a G Act 

b. iO:{A,Ae),s)^iiO:iA',A'e),s+) 

D 



(Throw) {throw, s) > (empty, s) (Exit) {exit,s) >■ (empty, s) 

(Receive) {receive{pl,op,v),s) ■ ■ ■ ' - — >■ [empty, s') 

where V £ Var, v' G 7,, op G OPS, pi G PL, and s' — {op{a[v' /v]), p). 

(Invoke) {invoke(pl, op, vi), s) ¥ [empty, s) 

eply{pl,V2) 



(Reply) [reply[pl, V2), s) >■ (empty, s') 

where v^ £ Var, Vq G X, pi G PL, and s — ('^[■i^g/^^s], p)- 

(R-eply) [reply(pl, v), s) "■ — >■ (empty, s) 

(Assign) [assign[expr, vi), s) '■ > [empty, s') 

where v^ € Var, expr is an arithmetic expression, and s — [(7[expr / v i] , p) . 

(Ai . s) — >■ (A-^^, s ), a ^ exit, a ^ throw 

(Seql) : 

[Ai;A2,s) — )■ [A-^^■,A2,s ) 

(Ai. s) — >■ (empty, s ), a ^ exit, a ^ throw 
(Seq2) 1 



^ [Av,A2,s) ^(A2,s) 

[Ai . s) — >■ (empty, s), (a ^ throw V a — exit) 

(Seq3) ^ —J ^ ^ ^' ^'^ ^ 

[Ai; A2. s) — >■ (empty, s) 

(Ai, s) — > (A-, , s ), a ^ exit, a ^ throw 

(Pari) ^ ' ^ ' ^ ■ 

(A^,\\A2,s)^^[A[\\A2,s') 

(A2, s) — >■ (^2,5 ), a ^ exit, a 7^ throw 

(Par2) 

(Ai||A2,s) A(Ai||A^,s') 
(Ai , s) — > {empty, s), (a — throw V a — exit) 



(Par3) 

(Ai||A2,s) A (empty, s) 

{A2 ■ s) — > [empty, s),{a — throw V a — exit) 

(Par4) — 

(-4i||/l2,s) A (empty, s) 
(Par5) (empty\\empty, s) — > (empty, s) 
cond(s) 

(Whilel) 

{while(cond. A) , s) — ^ (A; (while(cond. A) , s)) 
^cond(s) 

(While2) 

(while(cond. A), s) — > (empty, s) 

(Pick) (pick({(pli, opi,Vi, Ai)}"^-^, A,t), s) p ,,°Pi.f,. » ^ (Ai,s') 

where t > 1 , Vi ^ Var, v' E Z, opi G OPS, pk €: PL, and 5' — (opi((T[v^ /vi]), p) . 

createResource{EF'R,valA,A(,- ) 

(CR.) {createResource(EPR, val,t, Ae), s) — > (empty, s') 

where t > 1 , val G Z and s' = (ct, p U {EPR, val,lil, t, A^,}), if EPP. ( p. Otherwise, p' = p. 
s = (a,p),EPR£ p 

(GetProp) ^ — 7- 

(getProp(EPR,v), s) '■ > (empty , s ) 

where v G Var, 1;' G Z and s' — (a[v' / v], p). 
s = (cr,p),EPR ^ p 

(GetProp2) TJT^:^ 

(getProp(EPR,v), s) > (empty, s) 

s = (a,p),EPR G p 
(SetTime) 



setTimeout{EPB.,t) , 

(setTimeout(EPR,t). s) > (empty, s ) 

whore t > 1 , s' = (a, p[t/ EPR]i!). 

s = (a,p),EPR ^ p 

(SetTime2) TiZ!:^ 

(setTimeout(EPR, t), s) > (empty, s) 

s = (cr,p),EPR G p 

(SetTime3) TJ^T^u 

(setTimeout(EPR, 0), s) — ''°'"> (empty, s) 



Table 3. Action and delay transition rules without notifications. 



Finally, the outermost semantic level corresponds to the choreographic level, 
which is defined upon the two previously levels. In Table [71 we define the tran- 
sition rules related to the evolution of the choreography as a whole. 



(Throw) {throw, s) ¥ (empty, s) (Exit) {exit,s) >■ {empty, s) 

(Receive) {receive{jpl, op,v), s) ■ ■ ■ ' ■ — > {empty, s') 

where V G Var, v' G 1,, op G OPS, pi G PL, and s' — {op{(T[v' /v]), p). 

(Invoke) {invoke{pl, op,vi), s) '■ — '■ V {empty, s) 

eply(pl,V2) 



(Reply) (reply{pl, V2), s) >■ {empty, s ) 

where v^ G Var, v^ G ^, pi G PL, and s — {ctIvq/vq], p). 

(Reply) {reply(pl, v), s) '■ — ¥ {empty, s) 

(Assign) {assign{expr, vi), s) '■ > {empty, s') 

where vj G Var, expr is an arithmetic expression, and s — {a[expr / v i] , p) . 

{Ai. s) — > {A-^. s ), a ^ exit, a ^ throw 
(Seql) \ \ . \ . 

{Ai;A2,s) -^ {A-^\A2,s ) 

{Ai. s) — V {empty, s ),a ^ exit, a ^ throw 
(Seq2) . . 

^ (Ai;A2,s) A (A2,s') 

(Ai . s) — >■ (empty, s), (a ^ throw V a — exit) 

(Seq3) ^ _- ^ ^ ^ ^^ ^ 

{Ai: A2, s) — >■ {empty, s) 

(Ai . s) — > (A-, . s ), a ^ exit, a ^ throw 
(Pari) - ' V 1' ^ ^ 



(Ai||A2,s) A(A;||A2,s') 

{A2, s) — >■ {A2, s ), a ^ exit, a 7^ thr^ 
(Par2) — 



(Par3) 



{M\\A2,s)^{A^\\A'2,s') 
{Ai, s) — > (empty, s), (a — throw V a — exit) 



(Ai\\A2,s) — >■ (empty, s) 

(A2 . s) — > (empty, s), (a — throw V a — exit) 

(Par4) — 

(-4im2,s) A (empty, s) 
(Par5) (empty\\empty, s) — > (empty, s) 
cond(s) 

(Whilel) 

(while(cond. A), s) — > (A; (while(cond. A), s)) 
—^cond(s) 

(•While2) 

('while(cond. A), s) — > (empty, s) 

(Pick) {pick({(pli,opi,Vi, Ai)}"^-^, A,t),s) ' > (Ai,s ) 

where t > 1 , v^ (E Var, v^ G Z, opi (E OPS, pk G PL, and s' — (opi{(T[v^ /vi]), p) . 

createResource{EPR,val,t,Ae- ) 

(CR.) (createResource{EPR, val,t, Ae), s) — > (empty, s') 

where t > 1 , val € Z, and s' = (<7,pU {EPR, val,ll), t, A,..}) , if EPR ^ p. Otherwise, p' = p. 
s = (a,p),EPR£ p 

(GetProp) 7- 

(getProp(EPR, v), s) > (empty, s ) 

where v E Var, v' (E ^ and s' — {(t[v' /v], p). 
s = ((T, p) , EPR ^ p 

(GetProp2) throw 

(getProp(EPR,v), s) V (empty, s) 

s = (a,p),EPR e p 

(SetTime) setT.meo,.t(EPI?.t) , 

(setTimeout(EPR, t), s) ' — ¥ (empty, s ) 

where t > 1 , s' = (cr, p[t/ EPR]i,). 

s = (a,p), EPR. ^ p 

(SetTime2) ThT^ 

(setTivaeout(EPR, t), s) > (empty, s) 

s = (cr,p),EPR e p 

(SetTime3) 7^7^ 

(setTimeout(E P R, 0), s) — ^°^) (empty, s) 



Table 4. Action and delay transition rules without notifications. 



Definition 4 (Choreography operational semantics). A choreography is 
defined as a set of orchestrators that run in parallel exchanging messages: C = 



s ^ {a,p),EPR e p 

(Subs) ^ subscrihe(0,EPR,cond' ,Ae^) , 

{subscribe(0. EPR. cond ,Ae).s) ^ {einpty^s ) 

where s' — (a. Add^subs(p. EPR, O. cond' , A^)) 

s ^ (cr, p), EPR ^ p 

(Subs2) ^ jj^:^:^ 

(subscribe(0 , EPR, cond ), s) ¥ (empty, s) 

t > 1 

(Wait ID) -r- 

(waitit), s) —^1 (waitit — 1), s ) 

(Wait2D) {wait{l),s) -^i {e7npty,s+) 

(ReceiveD) {receive{pl,op,v),s)^-i (receive(pl,op,v),s ) 

(InvokeD) (i7ivoke{pl, op, vi,V2)t s) ^^i (invoke{pl, op, vi,V2), s) 

(EmptyD) {e7npty,s) -^i {empty, s) 



(SequenceD) 
(ParallelD) 



(Ai;A2,s) ^1 (A;;A2,s+) 



(Ai||A2,s)^i {A[\\A'2^s+) 
(PicklD) (picfe({(pii,opi,t>i, Ai)}lLi, A, l),s) -s-i (A, s+) 

t > 1 



(Pick2D) 



(pick({(pli, opi,i>i, Ai)}"^i, A, t), s) ->i (pick({pli,opi,Vi, Ai}"^-i, A,t - l),s^) 



Table 5. Action and delay transition rules without notifications. 



(Notifl) 



(Notif2) 



{A. s) — > {A . s ), a ^ exit, a ^ throw 
(O : (A,Ae),s) A (O : (A',A^\\N(0,s')),s') 

(Ae . , s) — ^ (Ag . , s ). a ^ exit, a ^ throw 

(O : (A,Ae),s) A (O : {A,A'j\N(0,s')),s') 
where A'^ = {A^ . }, A'^ . = A'^ . , j 7^ i. 

(NotifB) (A,s)^^^^:^{empt y^ 

(0:(A,A=),^)^^^^^2i^(0:(A^,A=)),^) 
(A, s) > {empty, s) 



(Notif4) - 
(NotifD) 



(O : (A, Ae), s) 7- (O : {empty, empty)), s) 

{A,s) ^1 (A',s+),(Ae;,s) ^1 (A;,.,s+),Vi 
(O : (A,Ae),s) ^1 (O : {A' , A'J\T{0, s)), s+) 



Table 6. Action and delay transition rules with notifications. 



{Oi}i=i, where c is the number of orchestrators presented in the choreography. 
A choreography state is then defined as follows: Sc = {{Oi : (^i, ^e*), Si)}i=i) 
where A, is the activity being performed by Oi at this state, Ae^ are the event 



handling activities that are currently being performed by O^, and Si its current 
state. 

D 



{Oi ; {Ai, Ae^). Si) > [Oi : (empty ^ empty) , s i) 

(Chorl) ■ 

{(Oj : {Aj,Ae'),Sj)y-^-^ ^^ {{Oj : (empty, empty), Sj)}''-^-^ 

(Oi : {Ai, Ae^), Si) — > (Oi : (Ai, A^ )■ Si), a ^ exit, a ^ receive, a ^ invoke, 
(Chor2) a ^ reply, a ^ reply, a ^ pick 

{(O, : (A,,A.J),s,)]]^^ ^ {(O, : {Ar,A':'),sr)r^^, 
such that A'- = Aj, A"^ = A^' \\N(Oj , s'-),Vj ^ i, j £ {1, . ..,c}. 

(Oi : iAi,Aj),Si) ^1 (Oi : (A'i,^"),Si + ), Vi G {1 . . .c},and rules chor4, chorS, 
fChorS) chorG are not applicable 

such that A'. = Ai, A'" = A^^\\T{Oi, Si + ). 

(O, : (Ai,A^'),Si) '"""'"''"''""'"''i (O. : {A'i,A'^'),s,), pi = {Oi,Oj), s, = i<7^,p^), 
(Chor4) (Oj : iA,,Aj),Sj) '''"'""''''''•°''''"''"'"> (Oj : {A'^ , A'^' ) , s'^) 

where A'fc=Afc, ^1"= = A,'' \\N{Ok, s'^) ifk^i,k^j. 

(Oi : (A,,>t/),Si) ""''''''''''"'> ( Oi : ( A'i,A'^'),s,), pi = (0^,0j), s, = {<7i, Pi), 
(ChorS) (Oj : (A,,A.^),s,) ""'"'"'•"''"") (O, : (A;M?),4) 

{(Ofc:(Afc,A^ ),Sfc)}fc=l > {{Ok ■■ iA^,A^ ):'>k)}k = l 

whore A)^ = Ak, A"'' = .Ae*" 1 1 W(Ofc , s'j^) i/ fe 7^ i,k ^ j. 

(O, : (Ai,Ae'),Si) '""■°''°<P'-°P'"l') (o, : (A;, A;,'),s,), pi = {Oi,Oj), s, = (o-,,p,), 
(Chore) (O, : (A,,A=^),s,) ""^"('"■"''■'-'-i'-^', (o^ , (A;,A','),4) 

{(O. : {Ak,A.''),Sk)}U^ ir..ok.(pi,ap..o, ^(Q^ ^ (a;,A1"=),4)}^_^i 
where A;„ = Ak, A'j" = A," \\N{Ok, s'^) ifk^i,k^j. 



Table 7. Choreography transition rules. 



Definition 5 (Labeled transition system). 

For a choreography C, wc define the semantics of C as the labeled transition 
system obtained by the application of rules in Table [3 starting at the state sqc- 



lt.s{C)^{Q,so,,^) 



where Q is the set of reachable choreography states, and 
ah basic activity a, or a = r }. 



u{- 



for 



D 



Example 1. Let us consider the choreography C — {O2, O2), where 
Oi = {PL^, Van, Ai, Af^,Ae,), 1=1,2, Vari = {vuVg}, Var2 = {wg, v^},^/, = exit, 
and Af^ = exit. Suppose that Sq, and sog are the initial states of Oi and O2, 
respectively, and all the variables are initially 0. Then, A2 = assign{5, vi ); 
receive{pli , add, W5); reply {pli , vg) and A2 = assign(l , v2); invoke{ph , add, wg). 
In Fig. [1] we show a piece of the labeled transition system of C, where: 

A'l = receive(pl\,add,vz);reply(pli,Vi). 
A'2 = invoke(pl\,add,V2)- 
A'i = reply (ph,V4). 
A'l = reply {pli,V3). 



{{Oi ■.lA[.tl)..,[).(0,:{A2.tl):ii«,)\ 



{(Oi: (,4;, »),,,;), (02:(,4;,9),»i)} 



{(o,:(-4';j),,,r),(02:(A;. »),,;)} 



{(Oi ; (A'l. 9), »;),(02;(Ai. »),»;)) 



{(O, : (™ipt,i/J),s;'),(0, : (4?J).s;)} 



{(Oi : (empij,,9),»"),(02 : {empty.tl).4)} 



Fig. 1. A piece of lts{C) without notifications. 



a 



5 Case study: Online auction service 



The case study concerns a typical online auction process, which consists of three 
participants: the online auction system and two buyers, Ai and A2. A seller 
owes a good that wants to sell to the highest possible price. Therefore, he in- 
troduces the product in an auction system for a certain time. Then, buyers (or 
bidders) may place bids for the product and, when time runs out, the highest 
bid wins. In our case, we suppose the resource is the product for auction, the 
value of the resource property is the current price (only the auction system can 



modify it), the resource subscribers will be the buyers, their subscription con- 
ditions hold when the current product value is higher than their bid, and the 
resource lifetime will be the time in which the auction is active. Finally, when 
the lifetime has expired, the auction system sends a notification to the buyers 
with the result of the process (the identifier of the winner, v^) and, after that, 
all the processes finish. Let us consider the choreography C — {Ogys, Oj, O2), 
where O, = {PL^, Var^, Ai, Af^,Ae,), i=l,2, Vargys = {v^,vepb., end_bid}, 
Vari = {vi , Utuj }, Varg = {wg, v^^}, Af, = exit, and Af^ = exit. Variable vepr 
serves to temporarily store the value of the resource property before sending; vi , 
V2, Vw, Vw-i, Vw2 are variables used for the interaction among participants, and, 
finally, end-bid is reset when the auction lifetime expires. Suppose sg, ,, sg^ and 
SOjj are the initial states of Osys, Oi and O2, respectively, and all the variables 
are initially 0: 

Asys — assign{l , end_bid); createResource{EPR, 25 , 48 , Anot)]while{end_bid > 0,Abid)- 

Ai = subscribe{Oi , EPR, EPR >= 0,Acondi)] while{vw^ == 0,Apick,) 

A2 = subscribe{02, EPR, EPR >= , Acond2)]while{vw2 =— 0,Apickg), being: 

Anot — assign{0, end-bid): (invoke^plg , bid_finishi , w„)||mwofce(pZ^ , bid-finish2, v^)) 

Abid = pick{{pk , cmp, vi , setProp{EPR, VEPR)),ipk, crnp, V2, setProp{EPR, vepr)), 

empty, 48) 
Acondj = getProp{EPR, vepr); invoke{pli , bid.up^ , vepr) 
Acond. = getProp{EPR, vepr); invoke^pk, bid.upg,VEPR) 
Apick, = pick{{pli , bid_upi , uj , invoke{pli , cmp, Vi ); subscribe{0 1 , EPR, EPR >=vi , 

, Acondj)), {pk, bid_finishi , vi , empty), empty, 48) 
Apick2 — P*cfc((p/g , bid_up2, V2, invoke{pl2 , cm,p, wg); subscribe{02, EPR, EPR >=V2, 

,Aconds)),{ph^ bid.finish2,V2, empty), empty, 48) 

In Fig. [2] we show a part of the labeled transition system of C, where: 

A'syg = while{endj}id > 0,Ai,id)- 
A'l = while{v^^ == 0,Apicki) 
A'2 = while{v^^ == 0,Apick2) 

A.I = Apickj j WllU€[Vmi ^^ U, Apicki) 

A2 = Apickg ] iviiile^Vw^ ^^ u, A.pick2} 
Asys = Abid', while{endj)id > 0,Atid)- 

Let us note that the operations bid_upi and bid-up2 are used to increase the 
current bid by adding a random amount to the corresponding variable Vi, the 
operations bid^finishi, bid-finish2 reset the value of Vw to finish both buyers. 
Finally, cmp is an auction system operation that receives as parameter a variable 
of the buyers, Vi, and if the variable value is greater than the current value of 
VEPR, then VEPR is modified with this new value. After that, by means of the 
activity setProp{EPR, vepr), we can update the value of the resource property 
with the new bid. 



a.^.^ign(l,£nd.bid};crratsR£soure£(EPR,2S,4S,A,^„i) 

Clioro ") »-(^ Chori 



■.ribe(Oi,EPR,EPR> — 0,A^^^^) 



;,bf.(Ol,EPn,EPR> = 0.A^^^^ , 



be(02:EPR,EPR> — fl,A^^j^^> 



^r Chori") ^C Chor,^ ' 



-(^2^^?)*- 



ic^i ll-^pii.fco 



Fig. 2. A piece of Its(C) for the online auction service. 



Choro = 
Chor2 = 

ChOTA = 

Chore = 
Chors = 
Chorio - 
Chori2 
ChoriA 



\\Usys 

XyCsys 

\\S-'sys 

XyUsys 

- \\Usys 

~ XK^ays 

~ Xy^sys 

~ XK^iyn 



(A,.,0),So.„J,(Oi : (Ai,0),SoJ,(O2 : (^2,0), So,)} Chor^ ^ {{Osy. : (A^,., 0), s(,.„J, (Oi : (Ai, 0), sqJ, (O2 : (^2,0), so J} 
iA',y,,9l),sl^J,iOi : (yli,0),SoJ,(O2 : (^2,0),so,)} Chor^ = {{Osys : (A'^y,, A.^nd,; A,ond,),sZyJ,{Oi : (Ai, 0), Sq J, (O2 : (A^,0),so,)} 
(^a..,0),4':„J,(Oi : «,0),SoJ,(O2 : iA'llD),So,)} Chor, = {{Osys : (A;,',,, 0), 4':^J, (Oi : (A'l, 0), Sq J, (O2 : (A^,0),So,)} 
(A^,.,^condJ,s(,':„J,(Oi : (A'i,0),soJ,(O2: (^^,0),so,)} Chorr^iiOsys : (A^,„ 0), ^"^J, (Oi : (A'/, 0), soj, (O2 : (A^,0),so,)} 
(A:,',„0),s[,':^J,(Oi : (Ai,0),soJ,(O2 : (A^,0),soj} C/iorg = {(O.,. : (A^,., ^co„d,), s[,':^J, (Oi : (A'l, 0), soj, (O2 : (A^,0),so.)} 
: (A^,.,0),4':,J,(Oi : (A'i,0),soJ,(O2 : (^^', 0), So.)} C/iorn = {(O.,. : (^'4^, 0), «[,':„ J, (Oi : (A'l, 0), soj, (O2 : (A^,0),so.)} 
: (A4.,A„oO,4':„J,(Oi : (A'i,0),soJ,(O2 : (4^,0), So,)} C/ions = {(O.,. : (empty, 0), s{,':^J, (Oi : (A'/, 0), soj, (O2 : (A^', 0), so,)} 
: (empfy,0),so' J,(Oi : (empty, 0), soj, (O2 : (empty, 0), so,)} 



6 Conclusions and Future Work 

We have presented in this paper a formal model for the description of com- 
posite web services with resources associated, and orchestrated by a well-know 
business process language (BPEL). The main contribution has therefore been 
the integration of WSRF, a resource management language, with BPEL, taking 
into account the main structural elements of BPEL, as its basic and structured 
activities, notifications, event handling and fault handling. Furthermore, special 
attention has been given to timed constraints, as WSRF consider that resources 
can only exist for a certain time (lifetime). Thus, resource leasing is considered 
in this work, which is a concept that has become increasingly popular in the field 
of distributed systems. To deal with notifications, event handling and fault han- 
dling, the operational semantics has been defined at three levels, the outermost 
one corresponding to the choreographic view of the composite web services. 

As future work, we plan to extend the language with some additional elements 
of BPEL, such as termination and compensation handling. Compensation is an 
important topic in web services due to the possibility of faults. We are also 
working on a semantics based on timed colored petri nets. 
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